home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 4303 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  6.7 KB
  1. Path: stc06.ctd.ornl.gov!mbk
  2. From: mbk@jt3ws1.etd.ornl.gov (Kennel)
  3. Newsgroups: comp.lang.java,comp.lang.eiffel,comp.lang.misc,comp.lang.c++
  4. Subject: Re: Constness in languages (Re: java weaknesses and peculiararities)
  5. Followup-To: comp.lang.java,comp.lang.eiffel,comp.lang.misc,comp.lang.c++
  6. Date: 29 Jan 1996 17:51:20 GMT
  7. Organization: Oak Ridge National Lab, Oak Ridge, TN
  8. Message-ID: <4ej1eo$s7@stc06.ctd.ornl.gov>
  9. References: <30FBED5F.28B8@achilles.net> <4dj4t4$a4@kai.com> <4e6dtm$si5@gaia.ns.utk.edu> <9602901.11916@mulga.cs.mu.OZ.AU>
  10. Reply-To: kennel@msr.epm.ornl.gov
  11. NNTP-Posting-Host: jt3ws1.etd.ornl.gov
  12. X-Newsreader: TIN [version 1.2 PL2]
  13.  
  14. Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
  15. > mbk@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN (Matthew B. Kennel) writes:
  16.  
  17. > >Arch Robison (robison@kai.com) wrote:
  18. > >
  19. > >: The keyword 'const' looks innocent at first, but introduces many
  20. > >: subtle complexities.  
  21. > [...]
  22. > >I think the problem with "const" as commonly known in C and C++ is
  23. > >that their model has a subtle, but fundamental intellectual error. 
  24.  
  25. > I disagree.  If you don't like `const' in C/C++, blame the subtle
  26. > complexities, blame the old code you have to interface with, blame the
  27. > language for not including `template on const', or blame the problems
  28. > on `const' not being the default.  But don't put it down to
  29. > intellectual error, because the C/C++ model of `const' is perfectly
  30. > consistent.  It may not be the only model around, and it may
  31. > conceivably not even be the best one, but I wouldn't call it erroneous.
  32.  
  33. I agree it's consistent: it's the notion that this kind of consteness ought 
  34. to be part of type which I think is an error in judgement.
  35.  
  36. I'm not talking about an "internal consistency or logical error". 
  37.  
  38. What is the motivation behind constancy?  To prevent human errors
  39.  
  40. > Personally I find `const' an extremely useful feature in both C and C++
  41. > and I am glad that they have it.  I think that if I used Java or
  42. > Eiffel, I would miss it.
  43.  
  44. > >Using Eiffelish terminology, "const" as typically done now is like
  45. > >a *precondition*, but the actual idea that it is supposed to uphold
  46. > >is really a *postcondition*.
  47.  
  48. > No, the idea that "const" in C/C++ is supposed to uphold is a type constraint.
  49.  
  50. Which is what I don't think is desirable. 
  51.  
  52. > A type consists of a set of values, and a set of operations on those
  53. > values (e.g. initialize, inspect, modify, ...).  A const type has the
  54. > same set of values, but a subset of the operations - only the ones that
  55. > don't modify the object (e.g.  initialize, inspect, ...).
  56.  
  57. And implicit conversions between const types and their 'regular' counter
  58. parts. 
  59.  
  60. Of course, with the right interfaces you can already explicitly make types 
  61. which present some full interfaces (permitting "writing") to some clients
  62. and which present restricted interfaces (permitting only reading) to others.
  63.  
  64. These things are already in the normal Eiffel typesystem.
  65.  
  66. > Types allow you to do that.  Given an ADT, a routine can only apply
  67. > the operations specified by that ADT.
  68.  
  69. > But types also allow you to do more.  Using postconditions only allows
  70. > you to ensure the constness of references passed to a routine.  Using
  71. > types also allows you to ensure the constness of references returned
  72. > from a routine.
  73.  
  74. Why do you always want to do that?  That's putting restrictions on what
  75. the caller can do with a thing.
  76.  
  77. The most common use of "const" you want to ensure that the routine didn't
  78. do anything nasty behind your back.  
  79.  
  80. Anthropomorphizing an object, "why
  81. should *I* not be allowed to modify some object?  I might even have
  82. created it for Ritchie's sake! I just want to make sure I can trust that
  83. Other Routine to not screw me over.  I don't want to 'marry the mob' and
  84. have it come back as a prissy 'const virgin'. "  
  85.  
  86. :-) 
  87.  
  88. Yes there are other uses for const, but I think those are better
  89. handled by regular types. 
  90.  
  91. > >The fundamental difference between pre- and post-conditions is that
  92. > >preconditions put restrictions the caller, whereas postconditions
  93. > >put restrictions on the callee.
  94.  
  95. > Right.  And types can put restrictions on both.  Which is exactly what
  96. > you want.
  97.  
  98. The example that started this thread was a demonstration of when such
  99. a notion had undesirable consequences:  forcing a needless massive
  100. "reconsting" of a program or preventing "const" from being used in a
  101. natural way. 
  102.  
  103. > Anyway, postconditions aren't sufficient, because if you want to pass a
  104. > reference to an object which is shared with another thread or which is
  105. > stored in ROM) you also need to be able to prevent intermediate
  106. > modifications.  Types will allow you to do that; postconditions won't.
  107.  
  108. But we already have types:  make an interface "NON_MODIFIABLE_FOOBAR"
  109. (or use Eiffel's qualified export capability) that says exactly what is
  110. and what isn't modifable.   I don't know about C++ but in Eiffel or Sather
  111. it's perfectly OK to hide modification routines of attributes from some 
  112. clients via interfaces. 
  113.  
  114. And you have the full power of normal types in an integrated whole 
  115. instead of the special "const/non-const" cross "user_defined_types".
  116.  
  117. A postcondition notion of const would express something intrinsically
  118. different from types, and would solve many of the interfacing problems
  119. people have with existing "const". 
  120.  
  121. > How is the compiler going to know which variables are aliased to which
  122. > other ones?
  123.  
  124. > Are you supposing that the compiler should be required to do global
  125. > aliasing analysis?  If so, what level of precision of analysis would
  126. > you require?
  127.  
  128. > That seems to me to be a very big problem for your approach.
  129.  
  130. > You are presuming that the compiler has perfect aliasing information
  131. > at compile time.  But this is not the case in any of the languages
  132. > under discussion.
  133.  
  134. Yes, you're right about that.  But C doesn't even try, right?
  135. I think aliased const modifications would have to be moved to a "warning"
  136. as not all could be detectable. 
  137.  
  138. > I don't understand.  In C++, "constifying" one routine will not require
  139. > any changes to its callers either, will it?
  140.  
  141. In the original example it did: you would have had to declare or
  142. make something a "const" type if I remember right.
  143.  
  144. > If these postconditions are statically checkable, then how do they
  145. > differ from type constraints?
  146.  
  147. Becuase they don't put any burden on the caller, which a type constraint
  148. does:  the notion of "const vs non const" leaks out because of the
  149. somewhat types. 
  150.  
  151. > How is treating constancy as a postcondition any different to treating
  152. > it as a type constraint?  What problem does it solve?
  153.  
  154. I can't find it now, but the original article in this thread showed
  155. the problem. It was a suggestion to add C++ const to Java, this example
  156. was part of the admitted problems you would get.  
  157.  
  158. > --
  159. > Fergus Henderson                 WWW: http://www.cs.mu.oz.au/~fjh
  160. > fjh@cs.mu.oz.au                  PGP: finger fjh@128.250.37.3
  161.